Local balance #3750
Local balance #3750
Conversation
|
I believe the updated handling of overdetermined connectors works, and to me is short and fairly intuitive. For the perfect matching I believe it is best discussed in #3763 - and some restriction added later. |
|
As far as I can see this improves the situation for:
With fairly small changes. It would be possible to formulate in various other ways, but I believe they will be equivalent - and I don't see any alternative that is clearly easier to understand. Note that we have improved the local check for these cases for Dymola 2026x (in particular when checking models with partial components which requires a local check, the usual balancing-error-pin-pointing is primarily an inclusive check according to the terminology in |
| For each declared component of specialized class \lstinline!connector! component, it is the number of unknown variables inside it (i.e., excluding parameters and constants and counting the elements after expanding all records and arrays to a set of scalars of primitive types). | ||
| \item | ||
| For each declared component of specialized class \lstinline!block! or \lstinline!model!, it is the sum of the number of inputs and flow variables in the (top level) public connector components of these components (and counting the elements after expanding all records and arrays to a set of scalars of primitive types). | ||
| If these public connector components contain overdetermined connectors each instance of an overdetermined type or record in that connector is assumed to be a separate root. |
There was a problem hiding this comment.
This is overly abstract and as I explained before the only way I am signing off on it is if other people prefer this formulation to what I proposed.
There was a problem hiding this comment.
So that others can find that alternative (which responded to a previous variant of this text):
An alternative to the count here is:
- For over-determined variables and equations, where the cardinality of the type is
cand the size of the residual isn:
- Over-determined connector variables are counted as
nvariables.- Declaration and equality equation of over-determined type are counted as
c.- Connections.root and Connections.branch are counted as adding
n - cequations.- Connections.potentialRoot is counted as adding
n - cif the root is selected and0otherwise.- Generated potential equations are counted as adding
nequations.
Originally posted by @qlambert-pro in #3750 (comment)
I have a hard time understanding how that description really works, as Connections.root and Connections.potentialRoot don't directly contribute to the global equation count (for potentialRoot there is normally an if-equation based on whether it is selected as root or not).
However, I can understand that this problem is abstract and complicated to get right.
The following are four cases that seem to covert this:
- A root-less component with one over-determined connector, like
Modelica.Mechanics.MultiBody.Forces.WorldForce - A component with a root and one over-determined connector, like a simplified
Modelica.Mechanics.MultiBody.Parts.Body - A (root-less) component with a pair of over-determined connectors connected to similar ones in a sub-component, like
Modelica.Mechanics.MultiBody.Forces.Spring - A (root-less) component with a pair of over-determined connectors connected to similar ones in two sub-component (like a parallel Spring and Damper variant built by components).
3 participants
I believe this handles all of the case, but there might be some remaining issue.